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METHOD AND SYSTEM FOR MANAGING CONTRACTUAL RISK 

BACKGROUND OF THE INVENTION 

[0001] The described technology relates generally to analysis of contractual terms 

and particularly to a computer system that manages the identification, tracking, 
and approval of high-risk contractual terms. 

[0002] Many companies and their customers use very detailed written contracts to 

specify the terms of their agreements to provide products or services. These 
contracts often need to be tailored to meet the specific needs of the customer. 
Large companies may have thousands of customers each with multiple contracts 
relating to various products and services that are provided by that company to the 
customer. A company, of course, wants to ensure that the terms of the contract 
do not expose the company to unnecessarily high risks. For example, a customer 
may propose a delivery date of six months after the contract is executed and 
propose that the company pay significant penalties for delayed delivery. The 
company's representative who is negotiating with the customer may not realize 
that, based on recent experience, a six-month delivery period is unrealistic. If the 
company were to agree to the proposed term, then the company would likely incur 
the significant penalties. 

[0003] To minimize the chances of entering into contracts with such high-risk 

terms, companies often have a contract review process that allows for a risk 
assessment to be made before each contract is executed. A company typically 
has a risk assessment team whose job it is to meet periodically and assess the 
risks associated with each contract. Before the risk assessment team meets, 
several reports may be manually generated by risk assessment analysts who try 
to point out the high-risk terms associated with each contract. The company may 
have a risk assessment analyst for each possible risk type. For example, a 
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company may have both a financial risk assessment analyst whose job it is to 
identify whether the financial terms present a high risk and a choice of law risk 
assessment analyst whose job it is to identify whether the choice of law in a 
particular venue presents a high risk. The risk assessment analyst may also 
suggest ways in which the terms of the contract can be modified to reduce the 
risk. In some cases, multiple risk assessment analysts are required to approve a 
particular variation. When the risk assessment team meets, it analyzes the 
various risk assessment reports and determines whether the contract is 
acceptable, acceptable with modifications, or unacceptable. The majority of the 
proposed contracts may use only standard contractual terms and thus are 
acceptable. The risk assessment team may, however, devote a significant 
amount of time deciding whether such proposed contracts are acceptable. In 
addition, each risk assessment analyst may apply different standards when 
assessing the risk of a term, may present their report in a very different format, 
may suggest very different modifications to the proposed contracts, and so on. 
Because of this lack of uniformity and because the reports are generated 
manually, it is difficult and time-consuming to assess the risk of proposed 
contracts. 

[0004] In addition, because sometimes anyone from a team of risk assessment 

analysts could approve a term, it is also sometimes difficult to track which risk 
assessment analyst gave the approval for a term and when they did so. 
Moreover, training new risk assessment analysts is often done manually and is 
therefore time-consuming and on an ad hoc basis, resulting in inefficient and 
sometimes inconsistent training. 

[0005] It would be desirable to have a risk assessment system that would help 

automate the process of assessing the risk of proposed contracts and projects in 
general, would provide uniformity in risk assessment, and would help speed up 
the process of risk assessment. 
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BRIEF DESCRIPTION OF THE DRAWINGS 



[0006] Figure 1 is a display page used to collect information about a proposed 

contract in one embodiment. 
[0007] Figure 2 is a display page used to collect information about risk factors 

associated with a particular proposed contract in one embodiment. 
[0008] Figure 3 is a display page used to collect information about a proposed 

contract and about approval of high-risk terms of the proposed contract in one 

embodiment. 

[0009] Figure 4 is a display page used to collect information about the person 

responsible for a proposed contract in one embodiment. 
[0010] Figure 5 is a display page illustrating a sample risk report for a proposed 

contract in one embodiment. 
[0011] Figure 6 is a block diagram that illustrates components of the contractual 

risk management system in one embodiment. 
[0012] Figure 7 illustrates a database schema for the contractual risk 

management system in one embodiment. 
[0013] Figure 8 is flow diagram illustrating a request to input a proposed contract 

in one embodiment. 

[0014] Figure 9 is a flow diagram illustrating the processing of a request to input a 

proposed contract in one embodiment. 
[0015] Figure 10 is a flow diagram illustrating a request for a contractual risk 

report in one embodiment. 
[0016] Figure 11 is a flow diagram illustrating the processing of the generate 

report component in one embodiment. 
[0017] Figure 12 is a flow diagram illustrating an approval of a variation of a 

proposed contract in one embodiment. 
[0018] Figure 13 is a flow diagram illustrating the processing of an approval of a 

variation of a proposed contract in one embodiment. 
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DETAILED DESCRIPTION 



[0019] A method and system for managing risk factors associated with a contract 

is provided. In one embodiment, the system receives information related to a 
contract. The contract information includes an indication of one or more 
variations to the contract. The system identifies an approver for each of the risk 
variations identified in the contract or one or more variations from a standard form 
of contract. The approver may be an individual or a group of individuals. The 
system then coordinates reception of approvals of the variation by the identified 
approver or approvers. When all approvals have been received, the system 
indicates approval of the contract. 

[0020] The system incorporates an identification of risks and contract risk 

standards as established by the company for a specified type of contract. The 
system then identifies variations from such standards in a particular contract. 
Alternatively, the system identifies variations from a standard form of contract 
established by the company. 

[0021] In another embodiment, the sytem stores the contract information and 

identifies one or more risk factors associated with each variation. The system 
may then identify one or more premises associated with each risk factor. Upon 
receiving a request for a risk report, the system may generate a risk report, which 
may include at least part of the contract information and an indication of the risk 
factors and premises associated with the contract and its variations. After 
generating the risk report, the risk report may be transmitted to a user. 

[0022] Variations to a contract will often result in triggering one or more risk 

factors. The risk factors identify certain aspects (e.g., high-risk terms) of a 
contract that might provide undue risk to the company executing the contract. 
Table 1 illustrates a risk factor table with associated premises. The table contains 
an entry for a wide variety of risk factors and a short description of those risk 
factors. Table 1 also contains sample premises that are associated with each risk 
factor. Premises are pre-defined ways in which a risk factor could be triggered. 
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For example, risk factor number seven is "Governing Law," which is the governing 
law for the contract, and sample premises are governing law in other states, 
governing law outside the United States, and governing law outside common law 
countries. These premises would differ from the standard contract term of, say, 
the laws of the state of New York. One skilled in the art will recognize that many 
risk factors and premises exist and are within the scope of the invention. 

[0023] 

[0024] Table 1 - Risk Factors 



it 


kisk ractor 


Description 


Sample Premises 


1 


Application of 
Technology 


Ability to use new 
technology in performance 
of agreement 


Customer approval required 
No substitution 


2 


Contracted 
Performance 


Performance guarantees 


Liquidated damages not 
sole remedy 

Performance guarantee < 
1 0% down 


3 


Contracting 
Entities 


Selection of contractor 
and deal structure 


Internal consortium 
Independent contractor 


4 


Contractor 
Responsibility 


Shall not be more than 
specified in standard 
contract 


Increased Contractor 
Responsibilities 


5 


Dispute 
Resolution 


Dispute resolution 
mechanism, forum, and 
venue 


Arbitration 
Outside U.S. 
Outside Europe 


D 


Excusable Delay 


No liability to extented 
performance prevent by 
excusable delay 


Strikes 

Wording Variation 


7 


Governing Law 


Governing law for the 
contract 


Other states 
Outside U.S. 
Outside common law 
countries 


8 


Indemnity 


Hold harmless provision 


Any other act/omission 
Customer property 
Wording deviation 


9 


Inventory 


Ability to substitute 
refurbished and third-party 
parts 


Limitation on right 
No right 


10 


Limitations on 
Liability 


Carveouts for potential 
damages 


Carveout for injury 
Carveout for punitive 
damages 
Monetary Caps 


11 


Model Variances 


Deviations from standard 


Model deviations 
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model output 




12 


Other 


Other deviations 


Other deviations 


A r\ 

13 


Owner 

Responsibility 


Details customer 
responsibilities 


Permits and licenses 
Other 


14 


Payment 


Security and currency 


Payment in other than U.S. 

currency 

Payment security 


15 


Payment 
Structure 


Structure of payments 


Quarterly payments 
Escalation clauses 


16 


Performance 
Data 


Customer must provide 
information on parts 


Inventory data 
Performance data 


A —J 

17 


Precommis- 
sioning Hours 


Initial factored fire hour 
computation 


Precommissioning hours 


18 


Safety 


Safety issues 


Hazards review 
Hazardous waste disposal 
Pre-existing conditions 


19 


Termination 
Provisions 


Ability to control 
termination 


Buy-out 

After a certain date 


20 


Title transfer & 
delivery 


Title transfer & delivery 


Consistent delivery 
Parts 


21 


Total Price 


Greater than a certain 
amount 


Greater than a certain 
amount 


22 


Unplanned 
Maintenance 


Cap on responsibility for 
unplanned maintenance 


Cap greater than a certain 
amount 


23 


New/Atypical 
Activity 


Work that is new or 
atypical for the 
organization 


New parts or software 
New environmental issues 


24 


Warranty 


Warranty information 


Exclusive remedy 
Duration greater than a 
certain time 
Other warranties 



[0025] Figures 1-4 illustrate sample display pages of a contractual risk 

management system in one embodiment. Figure 1 is a display page used to 
collect general information describing a proposed contract and its proposed 
variations. The example contract relates to providing services for power 
generation equipment, such as gas and steam turbines. One skilled in the art will, 
however, appreciate that the contractual risk management system can be used to 
manage the risks associated with contracts in virtually any industry or profession, 
including contracts for both goods and services. The display page 100 includes 
selection tabs 122. The selection tabs allow the user to choose the functionality 
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of the display page by selection either the contract tab, the terms & conditions tab, 
the variation tab, and the person details tab. When a user selects a selection tab, 
the contractual risk management system displays a display page through which 
the user can enter data relating to the type of tab selected. In the embodiment 
illustrated in Figure 1, the contract tab is selected, allowing the user to enter data 
relating to the proposed contract. 

[0026] Display page 100 includes a customer name field 102, an add customer 

button 104, a contract name field 106, and an add contract button 108. The 
customer name field is a drop-down list that allows the user to select a customer 
from a list of customers in the contractual risk management system. The add 
customer button will activate an add customer page or dialog box that allows the 
user to input a new customer into the contractual risk management system if the 
desired customer is not found in the customer name field. The contract name 
field is a drop-down list that allows the user to select a contract from a list of 
contracts in the contractual risk management system. In one embodiment, the 
contract name field lists proposed and/or existing contracts with the customer 
identified in the customer name field. The add contract button will activate an add 
contract page or dialog box that allows the user to input a new contract into the 
contractual risk management system if the desired contract is not found in the 
contract name field. In an alternative embodiment, new contracts and new 
customers may be automatically entered into the contractual risk management 
system from another system without need for manual input by a user. 

[0027] Display page 100 also includes a risk factor name box 110, a selected 

premise box 112, a risk factor description box 114, a risk factor selection field 
116, an available premise box 118, and a new risk factor description box 120. 
The risk factor name box lists risk factors associated with variations that have 
been proposed for the contract selected in the contract name field. For example, 
in display page 100 the risk factors associated with the proposed contract 
variations are governing law, dispute resolution, and excusable delay. The 
selected premise box displays the selected premises associated with the risk 
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factor selected or highlighted in the risk factor name box. In one embodiment, 
one risk factor is highlighted in the risk factor name box, and all of the premises 
that have been selected by a user related to that risk factor are displayed in the 
selected premise box. The risk factor description box includes descriptive 
information concerning the contracting standards of the company and the risk 
factor selected in the risk factor name box, and may also include information 
about any premises selected for that risk factor as displayed in the selected 
premise box. The risk factor selection field, the available premise box, and the 
new risk factor description box assist a user in selecting new risk factors and 
premises for the selected contract. The risk factor selection field allows a user to 
select a new risk factor from a drop-down list. The available premise box displays 
all of the available premises for the risk factor selected using the drop-down list of 
the risk factor selection field, and also allows the user to select one or more of the 
available premises. The new risk factor description box displays information 
about the selected risk factor and/or the selected available premise. The 
displayed information explains the justication for a particular risk factor and/or 
premise and the contracting standards for the company related to the justification, 
and also improves the training process for new employees. 
[0028] Display page 100 also includes a contract name field 124, a customer 

name field 126, identification number fields 128, a director field 130, a contract 
manager field 132, an original date field 134, and a close date field 136. The 
contract name field allows a user to input a name for the contract, while the 
customer name field allows a user to input the name of the other contracting party 
or customer. The identification number fields, in one embodiment, provide for a 
unique identification number or numbers for a contract. The director field and the 
contract manager field are drop-down lists that allow a user to select the names of 
a person or persons who have responsibility for the identified contract. In the 
depicted embodiment, the contract manager indicates the person with primary 
responsibility for the contract and the director field indicates the person with the 
business responsibility for the contract negotiation. The original date field 
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includes the date that the contract approval process was initiated in the 
contractual risk management system. The close date field is a drop-down list that 
allows a user to select a close date for the contract, which is the date which the 
contract is intended to be signed, providing the worst-case deadline for receiving 
approvals from all necessary parties. 

[0029] Figure 2 is a display page used to collect information about risk factors 

associated with a particular proposed contract in one embodiment. Display page 
200 is activated when a user selects the terms & conditions tab of the selection 
tab. Display page 200 includes selection tabs 122, a customer name field 102, an 
add customer button 104, a contract name field 106, an add contract button 108, 
a risk factor name box 1 10, a selected premise box 1 12, a risk factor description 
box 1 14, a risk factor selection field 1 16, an available premise box 118, and a new 
risk factor description box 120. The operation of these tabs, fields, and boxes is 
substantially similar to the operation of the similarly named tabs, fields, and boxes 
described in relation to Figure 1. 

[0030] Figure 2 also includes a selected risk factor box 202 and a save button 

204. The selected risk factor box provides a description and other information of 
the risk factor currently highlighted in the risk factor name box. In an alternative 
embodiment, the selected risk factor box instead lists all of the selected risk 
factors for the proposed contract and shown in the risk factor name box. The 
selected risk factor box includes an article column, a section column, a description 
column, a page number column, a point of contact column, a revision column, and 
a final reference column. The article column and the section column identify the 
location in the proposed contract where the variation is located so that the text of 
the variation can easily be found. The description column includes the name of 
the risk factor associated with the variation, and the page number further 
identifies the location of the variation in the proposed contract. The revision 
column identifies the latest revision of the proposed contract, and the final 
reference column specifies the location of the approved variation in the final 
version of the contract. The save button 204 allows a user to save all of the risk 
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factors, premises, user information, and other information that has been inputted 
upon selection of the save button. 

[0031] Figure 3 is a display page used to collect information about a proposed 

contract and about approval of high-risk terms of the proposed contract in one 
embodiment. Display page 300 is activated when a user selects the variation tab 
of the selection tab. Display page 300 includes selection tabs 122, a customer 
name field 102, an add customer button 104, a contract name field 106, an add 
contract button 108, a risk factor name box 110, a selected premise box 112, a 
risk factor description box 114, a risk factor selection field 116, an available 
premise box 118, and a new risk factor description box 120. The operation of 
these tabs, fields, and boxes is substantially similar to the operation of the 
similarly named tabs, fields, and boxes described in relation to Figure 1. 

[0032] Figure 3 also includes a premise box 302, a required approvals box 304, 

and a specific variation box 306. The premise box provides a description of the 
premise highlighted in the available premise box. Similarly to the function of the 
risk factor description box, this allows the user to understand the reasons 
underying the premise to improve understanding of the premise and training of 
new employees. The required approvals box identifies all of the individuals or 
organizations that must approve the variation identified by the selected premise. 
In the depicted embodiment, for example, the Risk/Reward manager and the 
Technical Evaluation & Modeling Manager must both approve the variation of the 
contract. The specific variation box allows users to input the exact variation to the 
contract that has been proposed. For example, the premise could be identified as 
governing law outside the United States, and the specific variation could be 
Japanese law. 

[0033] In one embodiment, the user could select a new available premise by 

"double-clicking" or otherwise selecting the premise highlighted in the available 
premise box. This would cause the highlighted premise to appear in the selected 
premises box, and the risk factor associated with that premise would appear in the 
risk factor name box. This process allows a user to increase the number of 
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premises and risk factors associated with proposed changes in the standard 
contract. 

[0034] Figure 3 additionally includes an approver list 308, an approved list 310, an 

approval status indicator 312, a save button 314, a delete button 316, and a deal 
complete indicator 318. The approver list is a drop-down list of all of the 
individuals or organizations that are required to approve the selected variation to 
the contract in order to complete the contract. The approved list is a drop-down 
list of all of the individuals or organizations that have already given approval of 
the selected variation to the contract. The approval status indicator provides an 
indication of not approved, partially approved, or fully approved. If no approvals 
have been received an indication of not approved will be used, if some but not 
approvals have been received an indication of partially approvied will be used, 
and if all approvals have been received an indication of fully approved will be 
used. Accordingly, the approval status indicator may be used to view the current 
status of the selected premise in a rough fashion. The save button is used to 
save any changes made to display page 300. To approve a variation, an 
authorized individual would select the appropriate option of the approver list (e.g., 
their name or position) and then select the save button. The delete button may be 
used to delete a premise highlighted in the selected premise box. This allows 
proposed changes to the contact to be removed by a user. Once the last premise 
associated with a risk factor has been deleted, the risk factor is also deleted from 
the risk factor name box. The deal complete indicator is activated when all 
required approvals have been received and the contract is therefore ready for 
signature. 

[0035] In an alternative embodiment, conditional approvals may be used. By 

adding language to the specific variation box 306, an approver may condition an 
approval upon certain deletions, additions, or other changes to the contract. This 
provides another way of streamlining the approval process, as an approver may 
not need to repeatedly review a proposed contract. 
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[0036] Figure 4 is a display page used to collect information about the person 

responsible for a proposed contract in one embodiment. Display page 400 is 
activated when a user selects the person details tab of the selection tab. Display 
page 400 includes selection tabs 122, a customer name field 102, an add 
customer button 104, a contract name field 106, an add contract button 108, a risk 
factor name box 110, a selected premise box 112, a risk factor description box 
114, and a risk factor selection field 116. The operation of these tabs, fields, and 
boxes is substantially similar to the operation of the similarly named tabs, fields, 
and boxes described in relation to Figure 1 . 
[0037] Figure 4 also includes name fields 402, a position field 404, a phone 

p number field 406, e-mail field 408, an update button 410, and a main menu button 

412. The name fields and the position field are used to identify the name and 
;Jf organizational position, respectively, of the person with responsibility for the 

u selected contract. The phone number field and the e-mail field provide contact 

7 information for the person identified in the name fields. The update button may be 

used to save any changes made to the information entered or any new 
rU information entered on display page 400, and the main menu button returns the 

user to a main menu page without saving any information entered or changed on 
display page 400. 

[0038] Figure 5 is a display page illustrating a sample risk report for a proposed 

contract in one embodiment. This report provides a summary of the contract, the 
proposed variations to the contract and the risk factors and premises associated 
with each variation, and the status of each required approval. A display page 500 
includes a contract information section 502, a risk factor section 504, a variation 
section 506, and an approval section 508. The contract information section 
provides information about the contract that is the subject of the risk report, such 
as the contract name, unique contract number, customer name, contract manager, 
etc. The risk factor section provides information about one or more risk factors 
associated with proposed variations in the contract, and also provides information 
about one or more premises associated with each risk factor. This includes 
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information about the current status of the proposed variation (e.g., not approved), 
the date that the information changed, and the identification of the person making 
the change. This allows the progress of a contract over time to be tracked, in 
addition to tracking the identity of the individuals approving a variation, changing 
information, etc. This information creates a persistent, auditable trail of the 
approvals required and obtained for each contract signed. The variation section 
includes the specific variation proposed for the contract. The approval section 
includes information about which required approvers have already given approval 
and which required approvers still have not given approval. 

[0039] The risk report of display page 500 provides a quick summary of the 

current status of a proposed contract, and in particular highlights the provisions of 
the contract that still need to be approved. The risk report of display page 500 
also provides a history of the approval of a contract, identifying the persons who 
approved variations and when they made such approvals. These reports may be 
used by a risk assessment team or management to track the progress of a 
contract, the response times of individual personnel, or other aspects of the 
contract approval process. One skilled in the art will recognize that many types of 
reports are possible and within the scope of the invention. For example, any type 
of metrics report may be created, such as for tracking the length of time to receive 
each approval, comparing the contract approval process for different 
technologies, geographic regions, or approvers, etc. Additionally, any type of 
summary report may be created, such as reports that indicate which contracts 
include a particular variation, risk factor, or premise, reports that summarize 
contracts approved over a certain timeframe, etc. 

[0040] Figure 6 is a block diagram that illustrates components used to implement 

the contractual risk management system in one embodiment. The risk 
management server 602 and one or more user computers 606 are interconnected 
via a computer network 604, such as the Internet or an intranet. A database 608 
may be in communication with the risk management server, or alternatively may 
be located within the risk management server. The computers may include a 
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central processing unit, memory, input devices (e.g., keyboard and pointing 
device), output devices (e.g., display devices), and storage devices (e.g., a hard 
drive, a CD-ROM, a floppy disk drive, etc.). The memory and storage devices are 
computer-readable media that may contain instructions for implementing the 
contractual risk management system. In addition, the data structures and 
message structures may be stored or transmitted via a data transmission medium, 
such as a signal on a communications link. Various communications channels 
may be used, such as a local area network, wide area network, or a point-to-point 
dial-up connection can be used. One skilled in the art will appreciate that the 
contractual risk management system can be implemented in other environments 
(in addition to the client/server environment) such as a single machine in which 
the contractual risk management software executes on a computer and accesses 
a database on the same computer. 
[0041] The risk management server includes an admin component 610, a web 

engine 612, an input component 614, a generate report component 616, a user 
database 618, a contractual risk component 620, and risk factor tables 622. The 
admin component allows an administrator to perform administrative tasks such as 
adding or deleting users, modifying data in the database, or defining permissions. 
The web engine receives requests, such as HTTP requests, from user computers 
and invokes the appropriate component of the contractual risk management 
system to service the request and provide responses, such as HTTP responses. 
The input component coordinates the entry of the contract information, risk factor 
and premise information, and variation information for proposed contracts. The 
input component stores the data in the database. Each contract may be identified 
by a unique project identifier. The contractual risk component manages the risk 
factors, premises, and variations for each proposed contract, as well as approvals 
or disapprovals of proposed variations. The generate report component compiles 
the contractual risk data by searching the database and generates the risk reports 
and other reports for the risk assessment team and management. The user 
database may contain an entry for each user authorized to use the contractual 
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risk managemnet system. The database may include a user name and password 
of each user for authentication and authorization purposes. Each user may have 
different levels of authority. For example, one user may have authority to create a 
new contract, while another user (e.g., an in-house counsel) may have authority to 
approve or disapprove for a certain risk factor or premise (e.g., choice of law 
outside the United States). The risk factor tables may include various tables that 
identify risk factors and premises and may be substantially similar to Table 1 in 
one embodiment. 

[0042] Figure 7 illustrates a database schema for the contractual risk 

management system in one embodiment. Figure 7 includes a number of data 
structures or tables that represent a relational data model. One skilled in the art 
would appreciate that the database schema may be organized very differently 
depending on the design choice of the developers. Figure 7 only represents one 
possible logical organization of the contractual risk management sytem. The 
actual design of the database may take advantage of well-known techniques to 
meet the speed requirements, response time requirements, and other 
requirements of a particular implementation of the contractual risk system. In one 
embodiment, a Microsoft Access or Oracle database may be used. The database 
schema of Figure 7 includes a contractjnaster table 702 with entries that include 
a contract identification number and a number of entries related to that contract, 
including a customer identification number, a commercial leader identification, a 
contract name, a contract original date, a contract manager identification, a 
variation field, a contract close date, and an approved indication. The 
contractjnaster table is linked to a customer table 704 with entries associating 
customer names with customer identification numbers. The contractjnaster table 
is also linked to a person table 706 with entries associating name, position, and 
contact information with person identification numbers (which may be equivalent 
to a contract manager identification or commercial leader identification). The 
person table is linked to a login table 708 with entries containing authorization 
information such as password, status, and a first time login indicator for each 
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person identification. The person table is also linked to a position table 710 with 
entries associating position identifications and position names. 
[0043] The contract_riskfactor table 712 has entries that map a contract to its 

selected risk factors. Each entry includes a contract identification (from the 
contractjnaster table) and a risk factor identification (from the risk_factor table 
described below). The contractjiskfactor table also includes a general variation 
field, which includes a general description of the variation typically associated 
with a risk factor. In an alternative embodiment, the general variation field 
includes the text description input by a user. The contract_riskfactor table allows 
each contract identification to have more than one risk factor associated with it by 
providing multiple entries for each contact. The risk_factor table 714 is linked to 
the contract_risk factor table and includes an entry for each risk factor. Each 
entry maps to a risk factor name and a risk factor description. The risk_factor 
table is also linked to a riskjactor^standard table 716. The riskjactor^standard 
table associates a risk factor identification with a standard term identification. The 
standard term identification is an identification of the particular standard term from 
the standard contract template associated with each risk factor. The 
risk_factor_standard table is linked to a standard_contract table 718. Each entry 
in the standard__contract table is associated with a standard term identification. 
The standard_contract table is similar to a table of contents for the standard 
contract terms. With each standard term identification there is an article code, a 
section code, a standard term description, a page number, a person identification 
(from a link with the person table), a previous standard term identification, and a 
standard term revision. The article code, section code, and page number identify 
where in the standard contract the standard term is located, while the standard 
term description provides a text description of the standard term. The person 
identification provides the name of the person responsible for the standard term, 
the previous standard term identification identifies the standard term that the 
variation is based upon, and the standard term revision indicates the version 
number of the standard term used as a baseline. 
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[0044] The contract_riskfactor_term table 720 is used to identify the location in 

contracts where variations are located. Each entry of the contract jriskfactorjerm 
table includes a contract identification, a risk factor identification, and a standard 
term identification. Each entry of the contractjnskfactorjerm table also includes 
a final reference, a final page number, a change date, and a standard/non- 
standard flag. The final reference and final page number indicate where in the 
final contract the variation is located. The change date indicates the date that the 
variation was last added or changed, and the standard/non-standard flag provides 
an indication of whether or not standard language was used in the contract. 

[0045] The contractjriskfactorjDremise table 722 maps a contract to its selected 

risk factors and selected premises. Each entry includes a contract identification, 
a risk factor identification, and a premise identification. Each entry also includes 
a specific variation, a variation change date, and a user identification. The 
specific variation is the text of the specific proposed variation to the standard 
contract or a description of the text, and the variation change date is the date 
when the variation was entered into the system. The user identification identifies 
the person proposing the variation, which may be the contract manager in one 
embodiment. 

[0046] The contract_riskfactor_premise table is linked to the riskfactor_premise 

table 724 that maps risk factors to their premises. Each entry includes a risk 
factor identification, a premise identification, and an approver group identification. 
The approver group identification identifies the group necessary to approve a 
variation for a particular premise and risk factor. The approver_group table 726 
has entries mapping approver group identifications and approver group names. 
The approver__group_position table 728 maps an approver group identification to 
a position identification. In one alternative embodiment, the approver_group table 
may be omitted and the riskfactor_premise table and the approver_group_position 
table are linked directly. The position identification includes a list of positions 
within an approver group (e.g., Risk/Reward Manager, In House Counsel, etc.). 
The riskfactor_premise table is also linked to a premise_catalog table 730, which 
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provides a catalog and description for premises. The premise_catalog table 
entries include a premise identification, a rank, a short description, and a long 
description. The rank identifies the rank of the premise within the list of premises 
associated with a particular risk factor. The short and long descriptions provide a 
summary or detailed description, respectively, of each premise. 

[0047] The contract__riskfactor_premise table is also linked to a 

contract_riskfactor_position table 732, where each entry contains a contract 
identification, a risk factor identification, a premise identification, and a position 
identification. This table is used to track the approvals that have been received 
for particular variations in order to create an auditable trail of approvals. The 
contractjiskfactor_position table also includes a person identification, an 
approval date, and a user identification. The person identification and user 
identification provide an identity of the person whose approval was received and 
the person who entered the information within the system, respectively. The 
approval date stores the date that the approval information was entered into the 
contractual risk management system. 

[0048] Figures 8-13 are flow diagrams illustrating processing of the contractual 

risk management system in one embodiment. Figure 8 is flow diagram illustrating 
a request to input a proposed contract in one embodiment. A user who wishes to 
enter a proposed contract into the contractual risk management system makes the 
request in order to seek the necessary approval for any variations from the 
standard contract, particularly with regard to high risk matters. In block 802, the 
user inputs user information, which may include a name, a user identification, a 
password, contact information, etc. In block 804, the user inputs basic information 
about the contract, which may include a contract name, a contract identification 
number, a date, a customer identification, a close date, a baseline contract, etc. 
Alternatively, some or all of the information in these blocks could be automatically 
entered based on pre-defined criteria. In block 806, the user inputs a risk factor 
(e.g., choice of law) associated with a proposed variation in the contract. In block 
808, the user inputs a premise associated with the risk factor selected in block 

[24376-8056/Appiication.doc] -1 8- 



806 (e.g., choice of law outside the United States, choice of law in a state besides 
New York). In block 810, the user inputs the specific variation desired in the 
proposed contract (e.g., choice of law in the province of British Columbia). In 
decision block 812, if all variations have been entered, the function continues at 
block 814; otherwise, the function continues at block 806. This allows the 
function to partially repeat so that multiple proposed variations may be entered. 
In block 814, the user inputs a save request or a delete request and the function 
then completes. The save request saves the inputted proposed contract while the 
delete request cancels the operation without saving the data. 

[0049] Figure 9 is a flow diagram illustrating the processing of a request to input a 

proposed contract by the input component in one embodiment. This function 
processes the request made by the user to input a proposed contract, as 
described in relation to Fig. 8. In block 902, the component receives user 
information and in block 904, the component receives basic contract information. 
In block 906, the component receives one or more risk factors associated with the 
proposed contract. In block 908, the component receives one or more premises 
associated with each risk factor. In block 910, the component receives the actual 
proposed variations associated with the specified risk factors and premises. In 
block 912, the component receives a request to save the received information. In 
one embodiment, the components receives all of the information simultaneously. 
In block 914, the component saves the contract and related information, which 
may be stored in a database, and the function then completes. 

[0050] Figure 10 is a flow diagram illustrating a request for a contractual risk 

report in one embodiment. The function of Figure 10 is used when a user who 
wishes to request a report from the contractual risk management system 
concerning a particular contract or group of contracts. In block 1002, the user 
inputs information about the contract, which may include a contract name, a 
contract identification number, or an indication of a range of contracts. In block 
1004, the user optionally inputs authorization information, which may include a 
user identification and a pasword. In block 1006, the user selects a type of report. 
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One skilled in the art will recognize that many types of reports are possible and 
within the scope of the invention, including reports concerning the approval status 
of an individual proposed contract, metrics reports based on different approvals, 
dates, customer identifications, time to complete approval, geographic region, etc. 
In block 1008, the user submits the request, which may include the data entered 
in blocks 1002, 1004, and 1006. In block 1010, the function receives a generated 
results display page or other embodiment of the complete report. In block 1012, 
the generated results display page is displayed to the user and the function 
completes. 

[0051] Figure 11 is a flow diagram illustrating the processing of the generate 

report component in one embodiment. The generate report component begins 
processing when a user on a user computer requests a report, as described in 
relation to Fig. 10, or could begin automatically or at pre-determined times. In 
block 1102, the component receives contract information from the user and in 
block 1104, the component optionally receives authorization information from the 
user. In block 1 106, the component receives information about the report desired 
by the user. In block 1 108, the component searches the database based on the 
contract information and the type of report desired by the user. For example, if 
the user desired a report about the status of a proposed contract, the component 
would search the database for all entries related to that proposed contract. In 
block 1110, the component generates the report based on the information found 
in the database, and in block 1112 the component generates a results display 
page. In block 1114, the component transmits the generated results display page 
to the user computer and the processing of the component completes. 

[0052] Figure 12 is a flow diagram illustrating an approval of a variation of a 

proposed contract in one embodiment. The function of Figure 12 may be used by 
a user on a user computer who desires to review the pending approvals related to 
a proposed contract and to register his or her approval or disapproval of the 
proposed variations for which he or she has approval authority. In block 1202, 
the function transmits information to the contractual risk computer, where the 
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information may include user information, authorization information, and 
information identifying the contract at issue. In block 1204, the function receives 
a list of proposed risk variations in the contract. These proposed variations may, 
in one embodiment, be displayed to the user. In another embodiment, only the 
proposed variations needing approval from the user are received. In block 1206, 
the user selects their name or organization or provides another indication of their 
identity and the fact that they want to submit an updated approval status. In block 
1208, the user selects a save button, which will register the user's approval of the 
changes to the contract. In one alternative embodiment, the user may selectively 
approve only some changes to the contract. In block 1210, the inputted 
information is transmitted to the contractual risk computer for processing, after 
which the function ends. The contractual risk computer may update the approval 
indicator to reflect the new approval (e.g., the contract would then be either 
"partially approved" or "fully approved"). 

[0053] Figure 13 is a flow diagram illustrating the processing of an approval of a 

variation of a proposed contract as processed by the contractual risk component 
in one embodiment. The contractual risk component will process the approval 
information received from a user as described in relation to Figure 12. In block 
1302, the component receives user information, authorization information, and 
information identifying the contract at issue from a user on a user computer. In 
block 1304, the component determines the proposed variations associated with 
the user, which may require searching the database. In block 1306, the 
component transmits the list of proposed variations to the user computer. In block 
1308, the component receives a list of modifications to the proposed variations 
(e.g., approval) from the user computer. In block 1310, the component saves the 
modifications to the database and then completes. 

[0054] From the above description, it will be appreciated that although specific 

embodiment of the contractual risk management system have been described for 
purposes of illustration, various modifications may be made without deviating from 
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the scope of the invention. Accordingly, the invention is not limited except by the 
following claims. 
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